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REMARKS/ARGUMENTS 

These remarks are being submitted in response to the Office Action dated 
November 19, 2004. Claims 1-7, 9-18, and 20-23 are pending in the present 
application. Independent claims 1,12, and 23 have been amended, and claims 1-7, 9- 
18, and 20-23 remain pending. The Examiner's indication that claims 2-7, 9-11, 13-18, 
and 20-22 would be allowable if rewritten in independent form including all the 
limitations of the base claim and any intervening claims is acknowledged and 
appreciated. 

Independent claims 1,12, and 23 have been amended to recite that images are 
uploaded from a hand-held image capture device to a server "over a network". Support 
for the amendment can be found throughout the specification, for example, the server is 
described as part of a photosharing website, and in a preferred embodiment, the image 
capture devices are described as being provided with wireless connectivity for 
connecting to the Internet (see pages 5-7 for example). Accordingly, it is respectfully 
submitted that no new matter has been entered. As this amendment makes clear what 
implicit in the claims, i.e., the presences of a network, this amendment is seen by 
Applicant as cosmetic, and as such, is not subject to the prosecution history estoppel 
imposed by Festo. 
SI 02 Reiections 

The Examiner rejected claims 1 and 12 under 35 USC §1 02(b) as being 
anticipated by Sarbadhikari (US 5,477,264). Applicants respectfully disagree. 

In contrast to the present invention, Sarbadhikari provides an electronic imaging 
system that includes an electronic camera for capturing and storing images in a 
removable storage device which is also preloaded with software for operating the image 
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system (column 2, lines 51-55). The removable memory may contain image templates 
or overlays for combination with user-captured images (col. 10, lines 24-28). The user 
selects images and overlays from a view screen. After images are captured and 
overlays the selected, the images and overlays are uploaded to a computer via the 
removable memory or a cable interface. 

Anticipation requires that the reference teach each and every element of the 
claims. It is respectfully submitted that Sarbadhikari fails to teach and suggest each 
and every element of the independent claims. First, Sarbadhikari fails to teach or 
suggest "a method for allowing a user to select actions to be taken by a server when 
uploading images from a hand-held image capture device," as claimed. Sarbadhikari 
discloses a computer for storing images uploaded from the digital camera, but nowhere 
does Sarbadhikari describe that the computer functions as a server or that the digital 
camera is connected to the server via a network. Rather, the images from 
Sarbadhikari's digital camera must be uploaded from the removable memory, or using a 
"standard electrical computer interface cable, such as a RS-232 or SCSI interface 
connection" (col. 11, lines 24-26). Accordingly, it is respectfully submitted that 
Sarbadhikari's disclosure as a whole dictates that the type of computer contemplated is 
a conventional PC, rather than a "server", as claimed. 

Sarbadhikari further fails to teach or suggest "downloading an action //sf from the 
server to the image capture device after the image capture device establishes a 
connection with the sen/er" as recited in step (a) of claim 1. The Examiner cites 
Sarbadhikari's frames/overlays for teaching an action list. However, as recited in 
independent claims, "the action list includes one or more items representing actions 
that the server should take with respect to uploaded images." In contrast, Sarbadhikari 
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defines a frame/overlay as "pre-existing image data files, i.e., files with images not 
captured by the camera system" (column 5, line 20). 

The Examiner cites Sarbadhikari for teaching that "while the captured image may 
be shown through the overlay in the viewfinder, the camera may not actually combine 
these images, but rather create a script file which would direct the computer to do the 
proper combination" (Col. 11, lines 5-9). In this embodiment, however, the camera 
creates the script, which requires client-side processing. In the present invention, no 
processing of any data is required by the actions "that the server should take with 
respect to images." 

Even if one assumes, that the script file can be considered analogous to "an item 
representing an action that the server should take, Sarbadhikari would still fail to teach 
or suggest "a list" of action items/scripts that are "downloaded" from the server to the 
image capture device, as recited in independent claims 1 and 12. Although 
Sarbadhikari refers to frames/overlays in the plural, not only does Sarbadhikari fail to 
teach or suggest "a list" of such items present on the removable memory, but also fails 
to teach or suggest that the list of such items is "downloaded" from the computer to the 
camera. The Examiner cites Sarbadhikari*s cable 38, figure 11 for teaching 
"downloading" an action list. Applicants, however, have studied Sarbadhikari and 
believe Sarbadhikari to only teach the uploading of data from the digital camera to the 
computer, not the reverse. Assuming arguendo, however, that the downloading of data 
to the digital camera from the computer is taught somewhere in Sarbadhikari, 
Sarbadhikari would still fail to teach doing so over "a network." 

Sarbadhikari also fails to teach or suggest "displaying the action list to the user 
on the image capture device after the user initiates an image upload process, as recited 
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in independent claims 1 and 12. Applicants understand Sarbadhikari's process to work 
as follows. First, the removable memory is provided with frames/overlays. The user 
then captures images, which are then stored on the removable memory. The user may 
then select images and overlays from the viewfinder of the camera, and the camera 
creates the script file that directs the computer to do the proper combination. And 
finally, the contents of the removable memory are uploaded to the computer, either 
directly from the memory card, or via a computer cable. Thus, in Sarbadhikari, the 
frames/overlays are displayed to the user before the user initiates the image upload 
process, rather than after, as recited in independent claims 1 and 12. 

Accordingly, because Sarbadhikari fails to teach each and every element of the 
independent claims, Sarbadhikari fails to anticipate the present invention under §102. 

The Examiner rejected claim 23 under 35 USC §102 (e) as being anticipated by 
Safai (US 6,167,469). Applicants respectfully traverse the rejection. 

In contrast to the present invention, Safai is directed to a method and apparatus 
for transporting digital images from a digital camera to a server. The digital camera 
executes a transport application that enables a user to send one or more pictures from 
the camera to one or more external addresses (column 7, lines 31-37). When the 
transport application is launched, a top-level view of the functions available in the 
transport application is displayed to the user (column 8, lines 21-27). As shown in 
figure 4A, the functions include selecting address, choosing a photo, recording a voice 
message, and sending a photo. 

The present invention is a server-side processing architecture, where a selected 
action is uploaded to the server along with an image and the server performs the action 
on the image. In contrast, Safai is directed to a standard client-server architecture that 
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is well-known in the art at the time and similar to the prior art discussed in the 
Background of the present application. In such client-server architecture, application 
software is required on the client device to process data prior to sending the data to the 
server. Thus, Safai fails to teach or suggest "A method for allowing a user to select 
actions to be taken by a server when uploading images from a hand-held image 
capture device, as recited in the present invention, because Safai requires the client to 
perform some, if not all of, the requested action. That is, the action request is sent to 
the client side application which begins processing the action. The processing may be 
completed on the server, but no action request or command is transmitted from the 
device to the server. On page 4 of the Office Action, the Examiner states with respect 
to Safai: "... and note that each action is stored in the camera's memory to be executed 
by the CPU to 10, figure 2) on the image capture device. Thus, the Examiner 
acknowledges that the actions are performed by the image capture device, rather than 
the server. 

Applicants further disagree that Safai teaches or suggests an "action list 
including one or more items representing actions that the server should take with 
respect to uploaded images, including any combination of specifying a storage location, 
sending the images to one or more email addresses; and analyzing or performing 
calculations on the images." Examiner cites Safai column 15, lines 27-58; column 13, 
lines 10-25; and column 14, lines 30-42. The sections, however, are not describing 
generic actions to be taken by the server; they are describing a routing mechanism. 
The operations performed by the server in Safai are determined by a valid address, 
which the user must enter on the camera. The actions in Safai are thus not predefined 
items as in the present invention. 
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In addition, Safai describes that each "action" selected results in an application 
being launched on the client (i.e., an email application for email, a print application for 
print, and a camera settings application for settings). This means that for any given 
"action", Safai requires executable code on the camera specific to the action to fulfill the 
request. The graphical interface sited by the Examiner includes four actions, two of 
which, image editing and change camera settings, are traditional client functions only. 
Safai describes neither of these actions so how they are processed is unknown. The 
processing of another action, "Print," is unclear since Safai does not describe its 
operation at all. Print functions on a camera were not unusual at the time of Safai's 
application, but the typical print functions are either a direct-to-printer command or 
through a PC host. Since Safai doesn't describe the print application, it's not clear what 
role the client and server play. Safai does mention printing in the context of the 
transport application, but it's merely a mechanism for delivering an image to a postal 
address and thus part of the transport applications routing function and not a general 
print feature. 

Of the applications displayed on the main menu of the client device, Safai only 
describes the detailed operation of the "Mail" or transport application. It appears that 
the Examiner has misinterpreted Safai's mail transport application as the action being 
performed by the server, when in fact, all the transport application does is route images 
based on the address and address type. The Mail application clearly requires client 
side processing, and the mail transport application does not send an action to the 
server, only photos, addresses, and voice messages. The action to be performed is 
fixed and implicit. It is hard-coded in the relationship between the client-side code and 
the server-side code. The server simply routes information based on address type (Col. 
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14, line 8 through Col. 15 line 11). The other services described by Safai are either 
initiated after upload time (e.g., from a web browser or remotely from the device) or also 
have a client specific piece and a server specific piece (print). 

It is respectfully submitted that the specification of an address, as in Safai, is 
non-analogous to an action request, since routing based on addresses and address 
type was well-known at the time and similar to the prior art email feature discussed in 
the Background of the present application. The printing feature referred to by the 
Examiner in this regard is merely another aspect of the routing function of the transport 
application. Printing only takes place when an addressee has a mailing address. It is 
not in this sense an action distinct from the general routing action performed by the 
transport application. No print request is sent from the client to the server, merely an 
address is sent. 

Accordingly, Safai fails teach or suggest each and every element of claim 23, 
and therefore claim 23 is patentable over Safai. 

In view of the foregoing, it is submitted that independent claims 1,12 and 23 are 
allowable over the cited references. Accordingly, Applicant respectfully requests 
reconsideration and passage to issue of claims 1-7, 9-18, and 20-23 as now presented. 
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Based on the foregoing, Applicant's attorney believes that this application is in 
condition for allowance. Should any unresolved issues remain, Examiner is invited to 
call Applicant's attorney at the telephone number indicated below. 



Respectfully submitted, 
SAWYER LAW QROUP LLP 



Februarv 22, 2005 




Date Stephen G. Sullivan 

Attorney for Applicant(s) 
Reg. No. 38,329 
(650) 493^4540 
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